System and method for providing remote data access for a mobile communication device

ABSTRACT

In one exemplary embodiment, a system for providing data access between an information source and a mobile communication device includes a transcoding system and a first network device. The transcoding system includes a plurality of transcoders, and each transcoder is operable to transcode information content from a respective first content type into a respective second content type. The first network device is in communication with the transcoding system and includes a connection handler system. The connection handler system is operable to receive connection data for a connection between the information source and the mobile communication device and to select a corresponding connection handler. The connection handler is operable to select one or more transcoders from the plurality of transcoders to transcode the information content.

This application claims priority from the following U.S. ProvisionalApplications: Ser. No. 60/305,044, entitled “System And Method ForProviding Remote Data Access For A Mobile Communication Device” andfiled on Jul. 12, 2001; Ser. No. 60/327,752, entitled “System and MethodFor Providing Remote Data Access To A Mobile Communication Device” andfiled Oct. 9, 2001; Ser. No. 60/330,604, entitled “System And Method ForProviding Remote Data Access And Transcoding For A Mobile CommunicationDevice” and filed Oct. 25, 2001; and Ser. No. 60/340,839, entitled“System And Method For Pushing Data From An Information Source To AMobile Communication Device” and filed Dec. 19, 2001. The completedisclosures of all of the above-identified provisional applications arehereby incorporated into this application by reference.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is also related to the following co-pendingNon-Provisional Applications: Ser. No. 10/483,457 entitled “System AndMethod For Providing Remote Data Access And Transcoding For A MobileCommunication Device” and filed on Jan. 8, 2004 which is a 35 U.S.C. 371filing of PCT/CA02/01073 filed on Jul. 12, 2002; and Ser. No. 10/483,116entitled “System And Method For Pushing Data From An Information SourceTo A Mobile Communication Device” and filed on Jan. 7, 2004, which is a35 U.S.C. 371 filing of PCT/CA02/01074 filed on Jul. 12, 2002, thecomplete disclosures of which are hereby incorporated into thisapplication by reference.

BACKGROUND

1. Field of the Invention

This invention relates generally to mobile communications, and inparticular to providing access to remote data from mobile communicationdevices.

2. Description of the State of the Art

Known solutions for providing remote access to data using mobilecommunication devices tend to be relatively limited. For example,Wireless Application Protocol (WAP) browsers for mobile devicestypically provide access only to information associated withWAP-compliant sources. Although other known and similar products mayallow a mobile device user to access further information sources, suchproducts generally do not make efficient use of mobile communicationnetwork resources, particularly wireless communication links, and oftenrequire processor-intensive operations such as information parsing to beexecuted on the device.

Furthermore, most known data access systems and methods are not suitedto provide truly secure access to confidential information stored onprivate networks, such as corporate information located on a data storebehind a security firewall.

SUMMARY

The instant application describes a system and method for providingmobile communication devices with access to remote information sources.

The systems and methods described herein provide for access to any of aplurality of types and formats of information. Information translationoperations may be performed on an information source side of a mobilecommunication system in order to reduce the complexity of deviceprocessing operations and any device hardware and software componentsassociated with such operations.

In one exemplary embodiment, a system for providing data access betweenan information source and a mobile communication device includes atranscoding system and a first network device. The transcoding systemincludes a plurality of transcoders, and each transcoder is operable totranscode information content from a respective first content type intoa respective second content type. The first network device is incommunication with the transcoding system and includes a connectionhandler system. The connection handler system is operable to receiveconnection data for a connection between the information source and themobile communication device and to select a corresponding connectionhandler. The connection handler is operable to select one or moretranscoders from the plurality of transcoders to transcode theinformation content.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a general block diagram of a communication system thatprovides access to a remote information source from a mobilecommunication device.

FIG. 2 is a more detailed block diagram of the system shown in FIG. 1.

FIG. 3 is a flow chart representing general connection handler-relatedoperations in the system.

FIG. 4 is a flow chart of connection handler data processing operations.

FIG. 5 is a signal flow diagram showing the extension of acceptedcontent types by an HTTP connection handler based on availabletranscoders.

FIG. 6 is a signal flow diagram showing multiple transcoding operationsfor an HTTP operation.

FIG. 7 is a general block diagram of a communication system with anexternal transcoder system.

FIG. 8 is a signal flow diagram illustrating an example HTTP operationfor an external transcoder system such as shown in FIG. 7.

FIG. 9 shows a further signal flow diagram for an external transcodersystem.

FIG. 10 is a block diagram of a communication system with an externaltranscoder system and an external connection handler system.

FIG. 11 is an example signal flow diagram for the system of FIG. 10.

FIG. 12 is a signal flow diagram illustrating delegation of aninformation request to an external connection handler.

FIG. 13 is a signal flow diagram showing a variation of the requestdelegation of FIG. 12.

FIG. 14 is a signal flow diagram showing hand-off of a request to anexternal connection handler.

FIG. 15 is a block diagram showing an IP Proxy system implemented in asecure network.

FIG. 16 is a signal flow diagram illustrating a corporate data accessoperation.

DETAILED DESCRIPTION

General System Description

FIG. 1 is a general block diagram of a communication system 10 thatprovides access to a remote information source 20 from a wireless mobilecommunication device (“mobile device”) 12. In FIG. 1, the system 10includes a mobile device 12, a wireless network 14, a gateway 15, a widearea network (WAN) 16, an Internet Protocol (IP) Proxy system 18, and aninformation source 20. Although an IP Proxy system 18 is shown in theillustrative example system of FIG. 1, proxy systems for protocols otherthan IP may be implemented in accordance with the systems and methodsdescribed herein. Protocols at other levels within the Open SystemsInterconnection (OSI) model can also be proxied using these systems andmethods. Such other protocols include, but are not limited to, HypertextTransfer Protocol (HTTP) and Transmission Control Protocol (TCP).

The mobile device 12 may be any mobile device adapted to operate withina wireless communication network 14, and is preferably a two-waycommunication device. The mobile device 12 may have voice and datacommunication capabilities. Depending on the functionality provided bythe mobile device 12, the mobile device 12 may be referred to as a datamessaging device, a two-way pager, a cellular telephone with datamessaging capabilities, a wireless Internet appliance or a datacommunication device (with or without telephony capabilities). As willbe apparent to those skilled in the field of communications, theparticular design of a communication subsystem within the mobile device12 will be dependent upon the communication network 14 in which themobile device 12 is intended to operate. For example, a mobile device 12destined for a North American market may include a communicationsubsystem designed to operate within the Mobitex™ mobile communicationsystem or DataTAC™ mobile communication system, whereas a mobile device12 intended for use in Europe may incorporate a General Packet RadioService (GPRS) communication subsystem. Those skilled in the art willalso appreciate that other types of mobile devices and networks are alsocontemplated. The systems and methods described herein may beimplemented in conjunction with virtually any wireless network 14.

The gateway 15 shown in FIG. 1 provides an interface between thewireless network 14 and a WAN 16, which may for example be the Internet.Such functions as device addressing, conversion of data between WANprotocols and wireless network protocols, storing and forwarding data toand from the mobile device 12, and other interface functions may beperformed by the gateway 15.

It is also possible that an IP Proxy could be hosted by a networkcarrier/operator associated with the wireless network 14. In this casethe connection between the IP Proxy 18 and the gateway 15 would use aprivate network of the carrier instead of the WAN 16. The WAN would thenbe used to communicate between the IP Proxy 18 and the informationsource 20.

The IP Proxy 18 is a system that effectively provides the mobile device12 with access to the information source 20 and is described in furtherdetail below. Through the IP Proxy 18, the mobile device 12 may accessany information source 20, such as an Internet or web server, that cancommunicate with the IP Proxy 18. The information source 20 thereforerequires no special applications or protocol support for wirelessnetwork communications, since it communicates with the IP Proxy 18 andnot directly with the mobile device 12. Although shown in FIG. 1 as adirect connection, the IP Proxy 18 and information source 20 may alsocommunicate through a network such as a local area network (LAN) or WAN,including the Internet.

Wireless networks and the Internet use similar addressing schemes, inwhich recipients, such as mobile devices in a wireless network orInternet-connected computers, are identified by numerical addresses. Forexample, mobile devices are identified in the Mobitex network usingMobitex Access Number (MAN) and public Internet nodes are identifiedusing an IP address scheme. However, differences between wirelessnetwork and Internet transport mechanisms prevent direct communicationbetween information sources 20, the vast majority of which areInternet-based, and mobile devices 12. Furthermore, information sourcecontent is largely targeted to desktop or other computer systems withrelatively powerful processors and may require that processor-intensiveoperations such as information parsing be performed by a recipient.Since mobile devices tend to have less powerful processors, theseoperations take more time on such devices than on computer systems andcan consume significant amounts of power from normally limited-powersources. The IP Proxy system 18 bridges the gap between Internet-basedand possibly other information sources 20 and a wireless network 14 withassociated mobile devices 12. The services supported by the IP Proxy 18may include address mapping, content transformation and verification,and protocol mapping and optimisation, for example.

Detailed Description of the IP Proxy

FIG. 2 is a more detailed block diagram of the IP Proxy 18 shown inFIG. 1. The IP Proxy 18 may include a dispatcher 22, a TCP handler 24,an HTTP handler 26, a transcoding system 28, one or more push servicesgenerally designated 30, a state persistence element 34, a monitoringsystem 36, and a logging system 38. FIG. 2 also shows a push server 42,a web server 46, a web browser 48, and a file system 40, with which theIP Proxy 18 may interact from time to time. Many of the components shownin FIG. 2 may be implemented primarily as computer software modules.Elements within the IP Proxy 18 will typically be running on the samecomputer, whereas components external to the IP Proxy 18 are normallyresident on separate computers. In an alternative embodiment, theelements of an IP Proxy may instead be distributed among a group ofcomputers distributed over a network.

Dispatcher 22 manages data flows and the connection to the gateway 15.Depending on the type of connection or the type of data beingtransferred or data transaction being performed, for example, thedispatcher 22 interacts with the TCP handler 24 or the HTTP handler 26.The transcoding system 28 comprises one or more data filters, each ofwhich converts data or other information from one format into a formatthat can be processed by a mobile device 12.

Push services 30 provide for transfer of “unsolicited” information froman information source such as push server 42, which may, for example, bea web server or a software application, to a mobile device 12 throughthe IP Proxy 18. The push services component 30 allows the push server42 to address the mobile device 12 using, for example, the email addressof the mobile device owner or some other convenient label. Accordingly,the push server 42 need not know the address of the mobile device 12 inthe wireless network 14.

The state persistence element 34, in conjunction with a data file system40 or a database, enables management of cookies, passwords and possiblyother state information associated with web servers 46 to which the IPProxy 18 may connect. It preferably stores state information about aconnection that persists between discrete network packets, such as anHTTP request/response pair. The monitoring system 36 allows remotemonitoring of the performance, efficiency, usage and health of an IPProxy 18 by an administrator through an interface such as a web browser48. As its name implies, the logging system 38 may be configured tostore usage, connection, user statistics and the like to the file system40 or some other secondary storage.

Connections and Handlers

The IP Proxy 18 can preferably handle and process content from variousinformation sources 20, including Internet-based sources. Thisfunctionality is provided by connection handlers, which are intermediateobjects that have the ability to process content from inbound andoutbound connections to an IP Proxy system 18. In the IP Proxy 18 shownin FIG. 2, two such handlers, the TCP handler 24 and the HTTP handler26, are shown. These handlers can preferably be replaced and customizedor additional handlers can preferably be added to an IP Proxy 18 asneeded. The connection handlers can optimise not just the content butalso the protocol. For example, some requests that would normally besent to the mobile device 12 (such as a request for a password) may beresolved by the connection handler, where requested data has been storedin the file system 40 or another store accessible to the connectionhandler, through the state persistence element 34, for example. Thisinstance of a protocol optimisation can adapt so-called “chatty”protocols to be more wireless friendly by reducing the amount of trafficsent over a wireless network to a mobile device, thereby reducing theeffects of wireless network bandwidth constraints and latency.

Outbound connections are made from mobile devices 12 in order to senddata to and receive data from other entities such as Internet nodes. TheIP Proxy 18 preferably receives connection requests from mobile devices12 using a particular protocol, such as a proprietary protocol called IPProxy Protocol or IPPP developed by the assignee of the presentapplication. Other protocols may also be used. The IP Proxy 18 thenestablishes an Internet connection, according to protocol and routinginformation provided by the mobile device 12 in the connection request,and translates and maps that connection to start forwarding data in bothdirections. A data filtering or transcoding process is invoked whenevernecessary, based on the type of content being passed over theconnection, for example. Such outbound connections will be described infurther detail below, in the context of web browsing operations.

Inbound connections can be used, for example, to implement a data pushmodel. In this model, a mobile device 12 may be sent information withouthaving issued requests to fetch the information, as is the case withoutbound connections. As described briefly above, mobile devices 12 mayexist on a different network domain than Internet nodes. The IP Proxy 18is responsible for bridging the Internet and wireless network domains.Thus, the IP Proxy 18 requires certain routing information to route thetraffic to a particular mobile device 12. In a push operation, at leastsome of this routing information must be provided by the Internet node,such as the push server 42, that issues the request to establish aninbound connection. The IP Proxy 18 may convert commonly knownaddressing schemes such as email or IP numbers into the appropriatewireless network address of an intended recipient mobile device 12.

Connection handlers in an IP Proxy system 18 are stream-based objects.When an outbound or inbound connection is requested, a virtual pipedstream is established between mobile device 12 and the appropriateconnection handler. The connection handler will be instantiated andstarted to process the content for the established connection. Loadingof the connection handler is based on a connection request, whichpreferably contains a reference to appropriate handler name that impliesthe type of the traffic that would normally go through the virtual pipedstream and the location of the handler that must be loaded if is notalready loaded. The functions of connection handlers include mappingInternet or other information source-side connections and mobiledevice-side connections, forwarding traffic between these connections,and loading and invoking the appropriate transcoders on informationdestined for a mobile device.

Every connection is preferably associated with an instance of aconnection handler. This is true even for a connection that does notrequire that content be processed by the IP Proxy 18, such as a pure TCPconnection between a mobile device and a server. This type of connectionhandler forwards content back and forward without making any sort ofmodification to the content, although it may make modifications to theprotocol. For clarity, those skilled in the art will appreciate thedistinction between the data or content (what the mobile devicerequested or is being sent) and the protocol (the “wrappers” andconversions required to deliver the data).

Connection handlers are also responsible for loading the appropriatecontent filters or transcoders. In the above example, if the web server46 returns Hypertext Markup Language (HTML) content for example, theHTTP connection handler 26 would then use an HTML transcoder in thetranscoder system 28 if the mobile device cannot accept HTML content.

FIG. 3 is a flow chart representing general connection handler-relatedoperations in an IP Proxy system 18. At step 50, the IP Proxy system 18receives a connection request, which as described above may relate to aninbound connection or an outbound connection. When the connection isassociated with a particular handler, such as an HTTP connection thatrequires HTTP connection handler 26, the appropriate handler is loadedand executed at step 54 and the connection is established, as indicatedat step 58. If the request is outbound (from the mobile device 12), thenthe dispatcher 22 examines the protocol type associated with theconnection request and delegates the connection to the appropriatehandler. Data may then be exchanged between a mobile device 12 and anInternet service, push server 42, web server 46 or other informationsource 20.

If certain connection handlers, such as for a pure TCP connection asdescribed above, are used for a connection, then the data may passthrough the IP Proxy system 18 unchanged. In some IP Proxy systemshowever, content sent over a TCP handler may be modified. When otherconnection handlers are used however, data destined for a mobile device12 may need to be converted into a suitable, final content.

FIG. 4 is a flow chart of connection handler data processing operations.At step 62, data destined for a mobile device 12 is received. Althoughlabelled as a response from a connection, following an informationrequest from a mobile device 12, for example, it will be understood thatdata received by the connection handler may instead be information to bepushed to the mobile device 12 from a push server such as 42 via pushservice 30. Based on the type of data received at step 62, theconnection handler determines at step 64 if transcoding is required. Ifnot, then the information is sent to the mobile device 12 at step 70.Otherwise, the appropriate transcoder is loaded and executed in step 66.The data is transcoded into an acceptable format in step 68 before beingsent to the mobile device 12, as described in more detail below. Theentity that initiates the communication, the mobile device 12 forfetched data or the push server for pushed data, can preferably insteadrequest a specific transcoder to do the transcoding of the fetched orpushed data.

A connection handler may be implemented in computer software as a Java™class file, placed in a certain directory in a file system such that anIP Proxy Java Virtual Machine (VM) may locate and load the file whenneeded or requested. As those skilled in the art will appreciate, Javauses CLASSPATH environment variable as a guide to where it shouldperform a lookup for user defined classes. In one embodiment, paths toconnection handlers are to be among the first listed paths in theCLASSPATH so that they would be loaded relatively quickly whenrequested. The connection direction (inbound or outbound) and the nameassociated with a connection handler may also play a role in definingthe full class name of a handler. Those skilled in the art willappreciate that the same scheme could be implemented using dynamiclinked libraries (DLLs) or dynamic shared objects (DSOs) depending onthe target operating system.

Connection handlers can be associated with a name that represents aprotocol at the application layer. For example, if a mobile device 12 isenabled with a web browser and may therefore request to open connectionto an Internet server such as 46, it would be appropriate to have HTTPas a name for that connection handler, as shown with connection handler26. The handler name may adhere to the known rules of naming packages inJava language. The handler name is in lower case; however, from an IPProxy point of view, it does not matter as long as the Java VM can loadthat connection handler. Any Connection Handler may also have its classname as Handler.class. An example of a valid full class name thatrepresents a connection handler is as follows:

-   net.rim.protocol.iplayer.connection.handler.<connectiondirection>.<connectionhandlername>.Handler.class    where connection direction can be either device, which implies    outbound connection, or server, which implies inbound connection.    Connection handler name is the name associated with the handler, for    instance, http, ftp, etc.

There are at least two ways that an information source such as anInternet node can establish a connection to a mobile device 12 throughthe example IP Proxy system 18 shown in FIG. 2: (1) using atransportation layer protocol directly, such as TCP, to open a directconnection to the IP Proxy 18, or (2) using a datagram protocol at theapplication layer, such as HTTP. The IP Proxy system 18 includes twocorresponding connection handlers, which may for example represent abasic IP Proxy system 18 which can process two of the most common typesof connection. The first is the TCP connection handler 24, associatedwith the name tcp, for example. The second is the HTTP connectionhandler 26, which may similarly be associated with the name http, asdescribed above. In addition to supporting common connection types,these connection handlers also satisfy requirements for MobileInformation Device Profile (MIDP) implementation at the mobile device12. However, the IP Proxy 18 and the mobile device 12 can be extended tosupport any other types of connections. In the IP Proxy 18, connectionhandlers may possibly be added by providing an application programminginterface (API) in the IP Proxy system 18 and developing new connectionhandlers that adhere to the API for example.

In one embodiment, connection handlers in the IP Proxy 18 are loadedfrom a local storage medium, for example a disk drive associated with acomputer on which IP Proxy software is running. In another embodiment,connection handler storage may also or instead be remote from the IPProxy system 18, such as in a storage medium accessible by the IP Proxy18 through a local area network (LAN) connection or even a WAN like theInternet. This embodiment allows sharing of a single directory ofconnection handlers among all IP Proxy systems 18 that can communicatewith the connection handler store. It is also be possible to have thirdparties extend the connection handler set by embedding the URL where theconnection handler java class can be found.

If connected to the Internet, a connection handler directory couldpotentially be accessed and thus shared by all Internet-connected IPProxy systems 18. Public Internet-connected connection handlerdirectories would preferably receive connection handler requests from IPProxy systems and in response transmit any requested connection handlersto the requesting IP Proxy system 18. A new connection handler may berequired by an IP Proxy system 18 when a mobile device 12 whichcommunicates with the IP Proxy system 18 downloads a new application orinvokes a new mobile device feature which uses a new connection schemeor a connection method that was not previously used by the mobile device12. A mobile device user or the new application or feature may then senda control message to the IP Proxy system 18, indicating for example thename of the required connection handler, perhaps the mobile deviceapplication that requires the new connection handler and an addressassociated with a connection handler directory from which the newconnection handler may be requested. The IP Proxy 18 would thenpreferably request the new connection handler from the directory. Aconnection handler directory could be implemented for example as a webserver accessible to an IP Proxy system 18 using HTTP requests.

When a connection handler is loaded from a remote source, the IP Proxy18 preferably stores the handler in a local store in order to providefor faster loading of the handler for subsequent operations involvingthe corresponding type of connection for either the mobile device 12 forwhich the connection handler was initially loaded from the directory ora different mobile device 12 supported by the IP Proxy system 18.Depending upon the memory resources available to an IP Proxy system 18,downloaded connection handlers may be stored indefinitely or for aparticular period of time. Alternatively, a least recently used or LRUreplacement scheme could be used to provide for more efficient use ofavailable memory by overwriting relatively less frequently usedconnection handlers when new handlers are downloaded. Other memorymanagement techniques could also be used to optimize local IP Proxyconnection handler storage arrangements.

Transcoding

Relative to computer networks such as the Internet, wirelesscommunication networks are slow. Any system that bridges the two, as theIP Proxy does, may have to transform Internet data so that it isformatted appropriately for a wireless network and mobile device. Thisprocess is referred to herein as filtering or transcoding, and usuallyinvolves such operations as compressing data from the Internet into amore compact format appropriate for wireless transmission.

In the following description, transcoding operations are illustratedprimarily in the context of the above example of an HTTP handler 26 andHTTP connection. The HTTP connection and handler example is particularlyuseful in that HTTP allows content tags in the form of MultipurposeInternet Mail Extension (MIME) types, which may be used to determine theappropriate transcoder for received information.

In accordance with the IP Proxy system 18 disclosed herein, there is asingle configuration file for each type of connection handler. In the IPProxy 18 for example, a single configuration file is associated with theHTTP connection handler 26 and includes information for all HTTP contenttranscoders. This configuration file is used to map transcoders tocertain content types. The IP Proxy 18 may consult this file todetermine which content transcoder it should load to manipulate anyreceived content destined for a mobile device.

In the configuration file, general rules are preferably specified forhow to define the mapping between content types and transcoders. Oneexample of a possible configuration file entry is as follows:

Entry = {[default] : { RSV | <Transcoder name>}} | { [[ InputType] | <->OutputType> ] : [ Transcoder name] }where

default indicates to the IP Proxy which default transcoder should beloaded in case there is no one transcoder associated with a receivedcontent type;

RSV is a set of reserved keywords that is used in configuration file,such as pass (i.e. forward data to the mobile device withouttranscoding) or discard (i.e. do not transcode or forward data to themobile device);

Transcoder name is the name of the mapped transcoder;

InputType indicates the input content type that the mapped transcoderaccepts, which for an HTTP transcoder configuration file may be a MIMEtype; and

OutputType indicates the output type, such as a MIME type for an HTTPtranscoder, that the transcoder generates.

By using a content transcoder configuration file new transcoders may beadded for use by the IP Proxy 18. Therefore, as new transcoders aredeveloped and become available, they can be added to the configurationfile for any appropriate connection handlers and can thereafter beloaded by a connection handier when required, and without affectingother components of the IP Proxy system 18. For example, configurationfile entries may be added without shutting down the entire IP Proxysystem 18, thus allowing dynamic expansion of data that can be convertedfor transmission to mobile devices 12.

In another embodiment, a common configuration file format for allconnection handlers is used, and thus a only single configuration fileentry need be prepared and can be added to the configuration file forany connection handler. The concept of a common configuration fileformat for all connection handlers can be further extended to providinga single configuration file for an IP Proxy 18. Such a configurationfile could be used by all connection handlers in the IP Proxy 18 todetermine which content transcoders are available and to select aparticular transcoder for received content. However, it should beunderstood that a common configuration file format is in no wayrequired. Some connection handlers may share a configuration file entryformat or even a single configuration file, whereas others supported bythe same IP Proxy 18 may have different configuration files and entryformats.

The IP Proxy 18 preferably loads a transcoder based on the availableinformation regarding the content type of the data being either pushedto or pulled from mobile device 12. The IP Proxy 18 may use accept andcontent type header fields to decide which transcoder should be loaded.Several illustrative example content transcoder loading control schemesare described in further detail below. Although these examples relateprimarily to HTTP connections and handlers, those skilled in the artwill appreciate that other connection types and handlers may use similararrangements and methods to select a transcoder when content is receivedat an IP Proxy system 18.

It should also be appreciated that a transcoder may instead be selectedbased upon information other than content types, including informationin a header portion or other portion of a connection request from amobile device, a response to a connection request, or a communicationfrom an information source including information to be pushed to amobile device. For example, an IP Proxy system 18 may be configured todetermine a type of the mobile device 12 to which data is to be sent.Transcoder selection by the IP Proxy system 18 could similarly be basedon a network address or other identifier of the mobile device 12. Mobiledevice- or device type-dependent transcoder selection schemes may besupported by providing a device or device type mapping table accessibleto the IP Proxy system 18, which maps devices or device types totranscoders. Alternatively, a configuration file may be adapted toinclude device or device type identifiers to thereby associateparticular transcoders with devices or device types.

In a similar manner, transcoders may be selected based on an address(such as a URL) or other identifier of an information source, to enableinformation source-specific transcoding. A mapping table or aconfiguration file accessible to an IP Proxy system such as 18, may beused to enable transcoder selection based on information source. Thistype of transcoder selection may be useful, for example, when aparticular transcoder is to be used to transcode any content thatoriginates from a specific website and is destined for a mobile device.

Although content type-based transcoder selection is the primary type oftranscoder selection scheme described below, any of these alternativeschemes may be used instead of content type-based transcoder selection.The alternative schemes may also be used to select a transcoder, forexample, when a transcoder indicated by a primary transcoder selectionscheme is not available, such as when a transcoder system does notinclude a transcoder configured to transcode a received content typeinto a content type that the mobile device is configured to accept.

An HTTP connection handler in an IP Proxy system 18 will normallyattempt to load a transcoder based on Accept line and the Content-Typeheader fields. The IP Proxy may load a transcoder if it has informationregarding the content type(s) that a mobile device 12 is configured toaccept and the content type that a server or other information source 20returns. For example, in this case the HTTP connection handler 26 in theIP Proxy 18 may use an lnputType->OutputType key format to consult itsconfiguration file when configuration file entries include content typefields, as in the above example file entry.

The HTTP connection handler 26 may also load a transcoder if it hasinformation only about the server or source 20 content type but not whatthe mobile device 12 can accept. In this case the, the IP Proxy 18 canuse the InputType key format to consult its configuration file. If theconnection handler is unable to determine which transcoder should beused, it will preferably load a predetermined default transcoder. Whenthe default transcoder is used, the IP Proxy 18 may send an errormessage to a mobile device 12 if the output content type of the defaulttranscoder is not acceptable by the mobile device 12 or if the defaultis discard (see the above example configuration file entry). Since mostdata pull-based information sources such as web servers do not embodyautomatic resend or retry functions when such delivery errors occur,error messages will normally be sent only to the requesting mobiledevice 12. A mobile device user may then send a new request to retrievethe information. However, when the information originates at a pushserver 42, an error may be returned to the sending server, which maythen initiate a new push operation.

Consider the case of a simple HTTP operation in which no Accept headeris specified. A mobile device user or an application on the mobiledevice 12 issues an HTTP request indicating no Accept header field ofcontent types that the mobile device 12 or application can accept. TheIP Proxy 18 may, in the absence of Accept header information, infer thatany type of content can be accepted and forward the request to theappropriate information source 20. When information content destined forthe mobile device 12 in response to the request is received by the HTTPconnection handler in the IP Proxy 18, the content is sent to mobiledevice 12 as is, regardless of content type. Since the mobile device 12in this case can presumably accept any content type, the HTTP handlerdetermines that no transcoding is required and therefore does not loador use any of the HTTP transcoders. Alternatively, the IP Proxy 18 maybe configured to attempt to match the returned content type with one ofits transcoders. In the event that an appropriate transcoder which cantranscode the returned content type is found, the transcoder is loadedand used to transcode the content for transmission to the mobile device12. Otherwise, the IP Proxy 18 may load the default transcoder ordiscard the received content.

Other mechanisms for coping with missing content type information in arequest from the mobile device 12 will be apparent to those skilled inthe art. The particular mechanism implemented in an IP Proxy system 18may for example be a default mechanism used by the IP Proxy system 18whenever an information request does not indicate an acceptable contenttype, dependent upon a setting in a mobile device user profile stored ina database accessible to the IP Proxy 18, or determined by an IP Proxyowner or operator. However, the mobile device 12 and any applicationsresident thereon are preferably configured to include accepted contenttype indicators in all information requests generated at the mobiledevice 12, in order to provide the IP Proxy 18 with reliable and currentinformation regarding the type(s) of content that a mobile device 12 canaccept. Pattern matching techniques may also be used to produce morecomplex default behaviour such as applying a transcoder to transcode alldata to a common output type regardless of the input type. The order ofsuch pattern/transcoder rules may connote priority.

As described above, there is preferably a transcoder configuration filefor each connection handler supported by an IP Proxy system 18, orpossibly a single configuration file shared by all connection handlers.Such a configuration file not only provides a mechanism for adding newtranscoders as they become available, but also allows a connectionhandler to quickly determine which transcoders are available in the IPProxy system 18 and then effectively extend the types of content thatcan be accepted in response to an information request.

FIG. 5 is a signal flow diagram showing the extension of acceptedcontent types by an HTTP connection handler based on availabletranscoders. Although FIG. 5 shows only those components of the IP Proxysystem 18 directly involved in the example of an HTTP request from amobile device 12, those skilled in the art will appreciate that othersystem components may also be present. In order to avoid congestion inthe drawings however, such components as 30 through 48 in FIG. 2 havenot been shown in FIG. 5.

In FIG. 5, an HTTP request is sent from the mobile device 12, through awireless network and possibly through a WAN and appropriate gateway tothe IP Proxy system 18. As described above, the mobile device 12 maycommunicate with an IP Proxy system 18 using a protocol other than HTTP,such as the proprietary IPPP. In such arrangements, although theconnection request conforms to a particular protocol, the request mayspecify a connection type or connection handler, HTTP in this example,associated with a different protocol. Therefore, references to HTTPrequests sent from a mobile device 12 should be interpreted to includeboth HTTP requests, if mobile device to IP Proxy communications are viaHTTP, as well as connection requests which conform to other protocolsbut specify HTTP or HTTP connection handlers and thus are interpreted byan IP Proxy as HTTP requests.

The connection request is received by the dispatcher 22, whichrecognizes the request as an HTTP request and loads the HTTP handler 26.In its Accept line, the request in this example specifies that themobile device 12 can accept a tokenized, compressed version of WirelessMarkup Language (WML) which is generally referred to Compiled WML orsimply WMLC. The HTTP handler then uses this accepted content type(WMLC) to perform a lookup in the configuration file 72, shown in thetranscoding system 28 in FIG. 5. It will be appreciated by those skilledin the art however, that the configuration file 72 might instead beexternal to the transcoding system 28, part of the HTTP handler 26, oreven external to the IP Proxy system 18 provided that the HTTP handlercan access the file. In most implementations, the configuration filewill be stored in a data store accessible by the IP Proxy system 18,typically on the same computer system on or in conjunction with whichthe IP Proxy 18 is running.

The HTTP handler 26 searches the configuration file 72 to determinewhich if any of its associated transcoders outputs the requested contenttype, WMLC. In one embodiment, a lookup table which maps input contenttypes to output content types for all configured transcoders isconstructed when transcoders are first loaded to the IP Proxy system 18.The IP Proxy system 18 then accesses the table and determines whichcontent types it can convert into the requested content type (WMLC). InFIG. 5, the configuration file 72 or alternatively a lookup table,includes entries for two transcoders, one for converting from WML toWMLC and the other for converting from HTML to WMLC. The HTTP handler 26then adds the extra MIME types (WML, HTML) that it can convert to therequested type (WMLC) and submits a request to the web server 76. Asshown in FIG. 5, the request prepared and sent by the IP Proxy 18 to theweb server 76 includes WMLC, WML and HTML in its Accept line.

The request preferably lists the accepted content types in order ofpreference. For example, since the mobile device 12 can accept WMLC,this type of content does not require transcoding and thereforepreferably appears first in the IP Proxy request. Other content typesmay then be listed in order of decreasing transcoding complexity, forexample, or based upon some other criteria. The order of preference ofcontent types may also be indicated explicitly, for example usingquality factors in the Accept line.

In response to an HTTP request from the IP Proxy 18, the web server 76returns requested content, in WML format in the example in FIG. 5, tothe IP Proxy 18. The HTTP handler 26 then determines that the returnedcontent is WML, loads the appropriate WML->WMLC transcoder 74 from alocal store for example, and executes the transcoder to convert thereceived content into WMLC. The WMLC content is then forwarded to themobile device 12, through the dispatcher 22. When WMLC content isreturned by the web server 76, the HTTP handler 26 forwards the contentto the dispatcher 22 without transcoding, whereas if HTML content isreturned, an HTML->WMLC transcoder would be invoked to convert thecontent to WMLC. Although FIG. 5 shows the response to the mobile device12 being handled by the dispatcher 22, similar protocol translation orconversion between HTTP used by the handler 26 and a communicationprotocol used by the mobile device 12 may instead be performed by theHTTP handler 26 or another IP Proxy protocol translation/conversionmodule.

As described above, if the returned content cannot be converted to therequested type, for example if the HTTP handler 26 does not have anappropriate transcoder or cannot determine the best transcoder to use,then the default transcoder is preferably used. An error message may bereturned to the mobile device 12 if the output of the default transcodercannot be accepted by the mobile device or the default transcoder isdiscard.

The Accept line extension by a connection handler is in no wayrestricted to single-transcoder operations. In the example of FIG. 5,each transcoder converts directly from one format into the requestedformat. Another embodiment, a more extensive search of the configurationfile 72 may be conducted or a more exhaustive lookup table may beassembled. Thus, multiple transcoders may be used to convert receivedcontent into a format or type that may be accepted by the mobile device.

FIG. 6 is a signal flow diagram showing multiple or “chained”transcoding operations for an HTTP operation. As in FIG. 5, FIG. 6 showsonly those components of the IP Proxy system 18 directly involved in anHTTP request from a mobile device 12 in order to avoid congestion in thedrawings.

An HTTP request is sent from the mobile device 12 to the IP Proxy system18, possibly through one or more intervening networks and interfacecomponents. As in the above example, the request is received by thedispatcher 22, which recognizes the request as an HTTP request and loadsthe HTTP handler 26. The HTTP handler 26 then consults the configurationfile 78 searching not only for transcoders that output WMLC, but alsofor transcoders that output content types that may be input to anytranscoder that outputs WMLC. Therefore, according to this embodiment,additional MIME types are appended to the header Accept line of an HTTPrequest based not only on transcoder outputs, but also on transcoderinputs. In FIG. 6 for example, the HTTP handler 26, perhaps in a firstsearch pass through the configuration file 78, finds the WML->WMLCtranscoder entry. The HTTP handler 26 may then repeat the configurationfile search for any transcoders such as the HTML->WML transcoder thatconvert content into WML, which it can convert into the requested WMLCcontent type, to thereby further extend the list of accepted contenttypes. The configuration file search may be further repeated by the HTTPhandler 26, depending for example on acceptable delays in HTTP requestprocessing.

In order to avoid the delays and demand on processing resourcesassociated with such multiple search passes through a configurationfile, a transcoder content type lookup table may be used. Whentranscoders are first installed in an IP Proxy system 18, acomprehensive mapping table is preferably constructed to map receivedcontent types to possible output content types. For example, in FIG. 6,a lookup table entry for WMLC content would indicate that either WML orHTML can be converted into WMLC. Such a table would also preferablyindicate that HTML->WMLC transcoding involves two stages of transcoding.The table might instead be organized into single- andchained-transcoding sections, whereby if only a single transcodingoperation is preferred, the single-transcoder part of the tableincluding an entry for the WML->WMLC transcoder would be accessed.Illustratively, a chained transcoder 82 that converts HTML to WMLC maybe created from the HTML->WML and WML->WMLC transcoders. The HTML->WMLand WML->WMLC transcoders may also be separately invoked.

If further transcoding operations and the associated processingoperations and time delays are acceptable, then the HTTP handler 26 mayperform a lookup of an accepted content type or possibly an input typefor a previously identified transcoder in a chained-transcoder sectionof the table. Preferably, the format of the transcoding configurationfile may be changed to represent just such a lookup table in order tospeed up the search. This may be accomplished, for example, byspecifying a path between content types involving multiple transcoders.

The determination of whether multiple transcoding operations will bepermitted may be made by the HTTP handler 26 either before or after thetable or configuration file lookup operation is performed, before anHTTP request is sent to the web server 80, or even after the requestedcontent is received from an information source 20. In the example ofFIG. 6, it should be apparent that multiple transcoders may be invokedto convert received content into WMLC. The Accept line in the header ofthe HTTP request from the mobile device 12 is therefore expanded toinclude WML and HTML in addition to WMLC. As described above, theaccepted formats are preferably listed in order of preference. SinceHTML requires two transcoding operations instead of the singletranscoding operation required to convert from WML to WMLC, WML ispreferably listed before HTML in the Accept line of the HTTP requestsent from the IP Proxy 18 to the web server 80. Similarly, WMLC requiresno transcoding and is preferably listed first in the Accept line.

It is also feasible for the chain of transcoders to include both localand remote transcoding services. These remote transcoding services couldbe transcoder files that the IP Proxy 18 discovers, downloads andexecutes or they could be web based transcoding services which receivedata in one format and return it in another, as described in furtherdetail below.

The web server 80 then returns the requested content, in HTML format inthe example in FIG. 6, to the IP Proxy 18 in response to the HTTPrequest. The HTTP handler 26 determines that the returned content isHTML, loads and executes the HTML->WML transcoder and then loads andexecutes the WML->WMLC transcoder on the WML result of the firsttranscoding operation. The resultant WMLC content is then forwarded tothe dispatcher 22 and then to the mobile device 12. If WMLC content isreturned by the web server 80, the HTTP handler 26 forwards the contentto the dispatcher 22 without transcoding, whereas if WML content isreturned, the WML->WMLC transcoder is invoked.

It is contemplated that the determination as to whether multipletranscoding operations are allowed will be made dependent uponpredetermined criteria such as maximum HTTP request processing time ormaximum content transcoding time or processor time for example. Thisdetermination might also take a user-specified priority into account. Ifhigh time priority (low time delay) is assigned by the user to asubmitted request, then single transcoder operations may be selected.Alternatively, if a high data priority is associated with a request,then any number of chained transcoder operations may be allowed in orderto get the requested data back to the mobile device in an acceptableformat. Other criteria which may be applied by a connection handlerinclude but are in no way limited to allowing chained transcoders onlyfor relatively small amounts of received content, only at certain timesof day, under specific current traffic conditions, or only when theconfiguration file or lookup table is stored in a local file system.Further criteria will be apparent to those skilled in the art and assuch remain within the scope of the present application.

In the case of a data push to a mobile device 12 from a push server suchas 42 (FIG. 2), if the server pushes data content but does not specify aMIME type, then the default transcoder is preferably used. If thedefault transcoder outputs a content type that cannot be accepted by themobile device 12, an error signal is preferably returned to the pushserver 42, which may then re-send the data to the mobile device 12. Theerror signal further preferably indicates to the push server 42 a reasonfor any such delivery failure, such that the push server 42 may attemptto remedy the delivery problem if possible before the data is re-sent.Where the data could not be delivered to the mobile device 12 because noMIME type was specified and the default transcoder could not transcodethe data into an acceptable content type for example, then the pushserver 42 may re-send the data with an appropriate MIME type.

Processing of a server data push with a specified MIME type may dependupon whether or not the IP Proxy 18 knows the content types that amobile device 12 can accept. Unlike the above example of an HTTP requestand response process, the IP Proxy 18 does not have a request from themobile device 12 indicating an acceptable content type when data isbeing pushed to the mobile device 12. If the IP Proxy 18 does not knowwhich content type(s) that the mobile device 12 can accept, then thedefault transcoder is preferably used. However, in this situation, theactive connection handler may instead consult the transcoderconfiguration file or lookup table to determine if a transcoder thataccepts the returned content type as input is available. If an availabletranscoder is found, then it is loaded and used to transcode thereceived content. If more than one appropriate transcoder is found, thenone of them, for example the transcoder having the first entry in theconfiguration file or the transcoder that was used previously, such asthe transcoder that was used most recently, to transcode data for theparticular mobile device 12 to which the content is destined, may beloaded and executed. A transcoder may also be selected and used on thebasis of a content type that was previously sent to the mobile device12.

External Transcoder Systems

As described briefly above, transcoders may be loaded as needed from alocal store on a computer system on which an IP Proxy system 18 has beenimplemented. In another embodiment, transcoders may also be loaded froman external store. FIG. 7 is a general block diagram of a communicationsystem with an external transcoder system.

The system 90 shown in FIG. 7 is similar to system 10 of FIG. 1 exceptfor the external transcoder system 86. Elements common to both systems10 and 90 have been described above. As shown by the dashed lines inFIG. 7, the IP Proxy system 84 may communicate with the transcodersystem 86 through some sort of direct connection such as a serial portor connection, through a WAN 16 such as the Internet, or through a LAN88 within which the IP Proxy system 84 and the transcoder system 86 areconfigured to operate. Other communication links between the IP Proxy 84and the transcoder system 86 will be apparent to those skilled in theart.

FIG. 8 is a signal flow diagram illustrating an example HTTP operationfor an external transcoder system such as shown in FIG. 7. As in thepreceding examples, an HTTP request is sent from the mobile device 12 tothe IP Proxy 84, indicating that WMLC content is accepted at the mobiledevice 12. The request is received by the dispatcher 22 in the IP Proxysystem 84, which determines that the request is an HTTP request and thusforwards the request to the HTTP connection handler 94. The HTTP handler94 may be substantially similar to the HTTP handler 26 in FIG. 2 forexample, although it operates somewhat differently than handler 24 toload content transcoders. The HTTP handler 94 intercepts the HTTPrequest from the mobile device 12 and may then refer to a transcoderconfiguration file 92 or a lookup table as described above to determinewhether or not any transcoders are available to convert other types ofcontent into a type that is acceptable at the mobile device 12. Ifentries corresponding to one or more appropriate transcoders are foundin the configuration file 92 or lookup table, then the HTTP handler 94preferably includes any further content types in a request that is sentto an information source such as web server 76. Web server 76 processesthe request from the IP Proxy system 84 and returns WML content to theHTTP handler 94. These operations are substantially as described abovein the preceding examples.

When the WML content is received by the HTTP handler 94, it ispreferably stored in a file system or other data store 98 while theappropriate transcoder is loaded. In the example of FIG. 8, the HTTPhandler 94 requests the required WML->WMLC transcoder from thetranscoder system 86. Although this request is shown in FIG. 8 as anHTTP request from the HTTP handler 94, it should be apparent that othertransfer mechanisms might instead be used by an IP Proxy system 84 toretrieve a transcoder from a remote transcoder system 86. For example,if the IP Proxy system 84 communicates with the transcoder system 86 viaa LAN 88 (FIG. 7), then a LAN protocol or data access and transferscheme could be invoked by the HTTP handler 94 in order to retrieve anyrequired transcoders. In FIG. 8, the transcoder system 86 locates therequested WML->WMLC transcoder among its available transcoders 96 andreturns the requested transcoder to the IP Proxy system 84.

Regardless of the particular transcoder transfer mechanism implemented,the IP Proxy system 84, or in the example of FIG. 8 the HTTP handler 94,receives and loads the returned WML->WMLC transcoder, as indicated at100. The previously received and possibly stored WML content may then beprocessed by the transcoder 100 to transcode the WML content into WMLCcontent acceptable by the mobile device 12, and a response containingthe transcoded content is returned to the mobile device 12 by thedispatcher 22.

If chained transcoder operations are enabled, then more than onetranscoder request may be made by the IP Proxy system 84 to thetranscoder system 86. Multiple transcoders may instead be requested in asingle request to the transcoder system 86. Processing of previouslyreceived content for chained transcoder operations may proceed either aseach required transcoder is loaded by the IP Proxy system 18, withintermediate transcoded content possibly being stored in a file systemor data store such as 98, or only when all required transcoders havebeen loaded.

When a transcoding operation is complete, a transcoder loaded from theexternal system 86 is preferably stored locally by the IP Proxy system84 in order to avoid subsequent requests to the external transcodersystem 86 for the same transcoder. Retrieval and loading of a transcoderfrom a local or internal store in the IP Proxy system 84 will typicallybe completed much faster than a request to a remote system and reducestraffic on the communication link between the IP Proxy system 84 and thetranscoder system 86. In such IP Proxy systems, the active connectionhandler, which is the HTTP handler 94 in FIG. 8, preferably determineswhether a required transcoder is stored in a local data store beforerequesting the transcoder from the external transcoder system 86.Depending upon the amount of available storage, transcoders may bestored indefinitely or for a certain predetermined period of time. Othermemory management schemes, such as over-writing stored transcoders on anLRU basis for example, may also be used when memory resources arelimited.

The configuration file 92 or transcoder lookup table may be adapted forexternal transcoder loading by including an indication of the locationof a transcoder in the configuration file or table entry for thetranscoder. The file 92 or table is preferably updated if a transcoderis stored to, or overwritten in a local memory, such that the activehandler can determine from the initial lookup operation whether thetranscoder must be loaded from the external transcoder system 86. When atranscoder has not been or is no longer stored locally, then the file 92or lookup table preferably indicates from where the transcoder may beretrieved. For a transcoder that may be retrieved through an HTTPconnection, the corresponding file or table entry may indicate the IPaddress of the transcoder system 86, whereas a network address may bespecified in the configuration file or lookup table when a LANconnection is used.

It is also contemplated that more than one external transcoder systemmay be implemented in a communication system such as 90. In such anarrangement, the configuration file 92 or lookup table would preferablyinclude entries for all transcoders that are available to an IP Proxysystem 84 through all of the external transcoder systems with which itcan communicate. An IP Proxy 84 may thereby download transcoders fromany of a number of transcoder systems via direct or network connections.Overall operation of an IP Proxy system 84 with multiple transcodersystems would be substantially as described above, except that differenttranscoder systems may be accessed, possibly using different transfermechanisms and communication protocols, for each data transcodingoperation. Chained transcoding operations may also potentially involvecommunication with different transcoder systems.

The configuration file 92 or lookup table is preferably arranged tofacilitate a simple resolution scheme when a particular type oftranscoder is available from more than one transcoder system. Althoughan IP Proxy system 84 may be able to access multiple transcoder systems,an owner or administrator of an IP Proxy system 84 may designate one ofthese transcoder systems as a preferred or default system from which theIP Proxy 84 first attempts to download a transcoder. The order ofpreference of transcoder systems for any transcoder available from morethan one transcoder system may for example be reflected in the order ofconfiguration file or lookup table entries. If the file or table isarranged by transcoder type, then entries corresponding to the mostpreferred sources for a particular transcoder are preferably listedbefore entries associated with other transcoder systems. Theconfiguration file or lookup table may instead be arranged according totranscoder system, with all entries for the default or preferredtranscoder system occurring first In both these example arrangements, anIP Proxy system 84 will preferably attempt to load a particulartranscoder from its preferred source before accessing any other sources.

It should be apparent from the foregoing description that if atranscoder in the configuration file or lookup table could not be loadedby an IP Proxy system 84, then an error may be returned to the mobiledevice 12 and possibly an information source 20, particularly when theinformation source is attempting to push content to the mobile device12. Failure to load a transcoder may also be resolved by findingalternative transcoders or chaining of transcoders. Another method toresolve transcoder problems is to modify the accepted line to remove thedata type that caused the problem, and resubmit the request to the webserver or information source 20.

As described above, new transcoders may be registered with an IP Proxysystem 84 by adding a corresponding entry to the configuration file 92or a transcoder lookup table. Therefore, when a new transcoder is addedto any external transcoder system, the configuration file 92 or lookuptable in each IP Proxy system 84 that may download transcoders from thetranscoder system is preferably updated accordingly. This may beaccomplished for example by configuring transcoder systems to sendupdate messages to the IP Proxy systems 84 when new transcoders areadded. A transcoder system may instead append an update message orindicator to responses to requests from an IP Proxy system 84 followingthe addition of a new transcoder. According to this scheme, an updatemessage or indicator may be appended to the response to an IP Proxysystem 84 the first time any transcoder is requested from a transcodersystem after a new transcoder has been added. An IP Proxy transcodingconfiguration file or lookup table may also be kept current with one ormore external transcoder systems by executing a discovery routine,whereby a registry of available transcoders is periodically queried to“discover” new transcoders as they become available.

FIG. 9 shows a further signal flow diagram for an external transcodersystem. In FIG. 9, not only the transcoder system 86, but also theconfiguration file 102 is external to the IP Proxy system 84 andtherefore may be shared among multiple IP Proxy systems. Communicationsbetween an IP Proxy 84 and the configuration file 102 may be via adirect connection or a network connection, and may be different fordifferent IP Proxy systems. For example, the configuration file 102 maybe maintained by an owner or operator of a particular IP Proxy systemwhich is linked to the configuration file by a direct communication,whereas other IP Proxy systems may communicate with the configurationfile 102 through local or wide area network connections. As above, theconfiguration file 102 may instead be implemented as a lookup table. Theconfiguration file 102 may thus be considered a registry, with which oneor more external transcoder systems such as 86 register availabletranscoders.

The operations outlined in FIG. 9 will now be described in detail. Whenan HTTP request is received by the dispatcher 22 in the IP Proxy system84, it is forwarded to the HTTP handier 94, which as described abovedetermines if any additional content types can be transcoded into themobile device-compatible WMLC format. In the example of FIG. 9 however,the configuration file 102 is remote from the IP Proxy system 84. If theconfiguration file 102 is accessible via HTTP, then the HTTP handler 94manages the transcoder lookup function with the configuration file 102.If the configuration file 102 is not adapted for HTTP, then a differentconnection handler may be invoked to facilitate the transcoder lookup orconfiguration file search.

Depending upon the transcoders available to the IP Proxy 84, the HTTPhandler 94 may expand the accepted content types in the request from themobile device 12 to include the additional content types that may betranscoded into WMLC format acceptable at the mobile device 12. Asabove, it is assumed that the web server 76 from which content isrequested returns WML content to the HTTP handler 94. One embodiment,the transcoding system 86 enables remote transcoding of content. Insteadof requesting and loading a WML->WMLC content transcoder from thetranscoder system 86, the HTTP handler 94 (or another connectionhandler, depending on the particular transcoder system and the transferschemes it supports) transfers the WML content to the transcoding system86. Within the transcoding system 86, the appropriate WML->WMLCtranscoder 104 a is executed and the WML content is transcoded into WMLCformat. The WMLC content is then returned to the HTTP handler 94, or toanother connection handler if IP Proxy 84 to transcoder systemcommunications do not use HTTP. When the WMLC content is returned by thetranscoding system 86 and received by the HTTP handler 94, possiblythrough another connection handler which communicates with thetranscoding system 86, it is forwarded to the dispatcher 22. Thedispatcher 22 then prepares a response including the WMLC content andsends the response to the mobile device 12. The HTTP handler 94 mayinstead prepare the response, which would then be translated (ifnecessary) by the dispatcher 22 to conform to a communication protocolor scheme used by the mobile device 12. Illustratively, the WML contentreturned by the web server 76 may be stored by the HTTP handler 94 incase a data transfer or transcoding error occurs. Local storage of theWML content allows an IP Proxy system 84 to re-submit the content fortranscoding, to the same transcoder system 86 or a different transcodersystem, without first having to request the content from the web server76.

In the system of FIG. 9, it is contemplated that the transcoder system86 and configuration file 102 may also communicate with each other toensure that the configuration file 102 accurately indicates whichtranscoders are available. One of the update schemes described above maybe used to ensure that the configuration file remains current. Aconfiguration file may be associated with a particular type ofconnection, such as HTTP connections and thus HTTP connection handlers.If a configuration file 102 is associated with a particular transcodersystem 86, then the configuration file may be resident within thetranscoding system 86. If multiple transcoding systems are implemented,a shared configuration file storing transcoder entries for thetranscoders available in all transcoder systems may simplify thetranscoder lookup performed by a connection handler. An IP Proxy system84 need then only consult a single configuration file to determine ifappropriate transcoders are available from any transcoder systems withwhich it can communicate. This single configuration file/server couldalso support protocols to allow external transcoding servers toregister. This registration process could add a list of availabletranscoders to the single configuration file, for example.

External transcoder systems 86 therefore include download systems fromwhich transcoders may be downloaded by an IP Proxy system 84 andexecuted locally (see FIG. 8) and remote transcoding systems to whichcontent is sent for transcoding at the transcoding system (see FIG. 9).In another embodiment, a “hybrid” transcoder system incorporates aspectsof both these types of transcoder systems. When a hybrid transcodersystem is available to an IP Proxy system 84, the IP Proxy system 84 mayeither download a required transcoder from the transcoder system or sendcontent to the transcoder system to be transcoded remotely. Theselection of transcoder download or remote transcoding may be dependent,for example, upon the amount of data to be transcoded, the complexity ofthe transcoding (single or chained operations), or other criteria.

External Connection Handler Systems

A further extension of the concept of a distributed IP Proxy system withexternal, possibly shared components is shown in FIG. 10. FIG. 10 is ablock diagram of a communication system with an external transcodersystem 86 and an external connection handler system 108. The system 110of FIG. 10 is substantially the same as the system 90 in FIG. 7, exceptthat connection handler system 108 is external to the IP Proxy system106. The IP Proxy system 106 can download connection handlers from theconnection handler system 108 via a direct connection, a LAN 88, or aWAN 16 such as the Internet.

FIG. 11 is an example signal flow diagram for the system of FIG. 10. InFIG. 11, the connection handler system 108, the transcoder system 86,and the configuration file 102 are all external components and thereforemay be shared among multiple IP Proxy systems 106. These externalcomponents may be implemented for access by all IP Proxy systems 106owned and/or operated by a company, an Internet Service Provider (ISP)or an Application Service Provider (ASP) for example, such as through acompany intranet, dial-up connection or other communication arrangement.The connection handler system 108, the transcoder system 86, and theconfiguration file 102 might instead be publicly accessible to any IPProxy 106 through the Internet. Those skilled in the art will appreciatethat an IP Proxy system such as 106 may potentially have access to bothprivate, possibly corporate-, ISP- or ASP-based external components, aswell as public connection handler systems, configuration files ortranscoder systems. As above, communications between an IP Proxy 106 andexternal components may be via a direct connection or a networkconnection, and may be different for different IP Proxy systems.

By way of example, the operations associated with a system such as 110will be described below for an HTTP request. When an HTTP request isreceived by the dispatcher 22 in the IP Proxy system 106, an appropriatehandler may have to be downloaded from the connection handler system108, unless the handler is already resident on the IP Proxy 106 asdescribed in further detail below. This is shown in FIG. 11 as a handlerrequest, which may be processed through a resident handler 112 such as aTCP handler that is compatible with the connection handler system 108.This resident handler 112 will normally be provided locally on an IPProxy system 108 in order to enable communication between an IP Proxysystem and an external connection handler system 108. However, thehandler may instead be downloaded by an IP Proxy system 106 from aconnection handler system, preferably through an automated downloadprocedure.

The handler 112 then requests the appropriate connection handler, anHTTP connection handler in this illustrative example, from the externalconnection handler system 108. If the required connection handler isunavailable or cannot be downloaded, then an error may be returned tothe mobile device 12. If the required HTTP connection handler 108 a isreturned by the connection handler system 108 however, it is loaded bythe IP Proxy system 106. The dispatcher then forwards the original HTTPrequest from the mobile device 12 to the HTTP handler 108 a. The HTTPhandler 108 a may determine whether any additional content types can betranscoded into the mobile device-compatible WMLC format. As describedabove, this determination may be made by performing a transcoder lookupin a local configuration file or lookup table or external configurationfile 102 or lookup table. If the configuration file 102 is accessiblevia HTTP, then the HTTP handler 108 a manages the transcoder lookup;otherwise, a different connection handler may be invoked, possibly aftera further connection handler download operation, to facilitate thetranscoder lookup or configuration file search.

Depending upon the result of the transcoder lookup, the HTTP handler 108a may expand the accepted content types in the request from the mobiledevice to an information source such as a web server 76. As above, it isassumed that the web server 76 returns WML content to the HTTP handler108 a. The returned WML content may be transcoded into WMLC content byinvoking a WML->WMLC transcoder stored in a memory in the IP Proxysystem 106, by downloading a WML->WMLC transcoder from an externaltranscoder system and then invoking the transcoder at the IP Proxysystem 106, or by sending the WML content from the IP Proxy system 106to an external transcoder system 86 for remote transcoding by aWML->WMLC transcoder 104 a in the transcoding system 86. Although asingle transcoder operation is shown in FIG. 11, chained transcodingoperations and any necessary associated downloading or transferoperations may also be performed. When WMLC content is then returned tothe HTTP handler 108 a, possibly through another connection handler ifIP Proxy 106 to transcoder system 86 communications do not use HTTP, aresponse including the WMLC content is prepared and sent to the mobiledevice 12 through the dispatcher 22.

The external connection handler system 108 provides for an extension ofthe types of connection through which an IP Proxy system 106 may accessdata to be sent to a mobile device 12. Once downloaded from an externalconnection handler system, a connection handler such as HTTP handler 108a may be stored by an IP Proxy system 106 to a local data store. In suchsystems, the dispatcher 22 would preferably access the local store todetermine if a required handler is already resident within the IP Proxysystem 106. Subsequent downloads for previously used connection handlerscan thereby be avoided. Download operations may be further reduced byproviding one or more of the most commonly used connection handlers in alocal memory on initialization of an IP Proxy system 106, such that onlyless frequently used connection handlers are downloaded from an externalconnection handler system as needed.

Similar to the external transcoding system described above; an externalconnection handler system may be either a download system, as shown inFIG. 11, or a remote connection handling system, in which connectionhandlers are invoked and executed on the connection handler systeminstead of being downloaded for execution on the IP Proxy system 106. Inthe example of an HTTP request, when remote connection handling isenabled, a request from the mobile device 12 may be either delegated orhanded off to the external connection handler system.

FIG. 12 is a signal flow diagram illustrating delegation of aninformation request to an external connection handler. In the example ofFIG. 12, a request from the mobile device 12 is received by thedispatcher 22 in the IP Proxy system 106 a and forwarded to the residenthandler 112. Although referred to as a resident handler, the handler 112may have been downloaded to the IP Proxy system 106 a from an externalconnection handler system. The resident handler 112 may then consult atranscoder configuration file 72 and extend the accepted content typesin the request. It will be apparent from the foregoing description thatan external configuration file may also be implemented. The residenthandler 112, which as described above is compatible with the connectionhandler system 108, forwards the request, possibly having an extendedAccept line, to the connection handler system 108. The connectionhandler system 108 determines that the request is an HTTP request andinvokes the HTTP connection handler 108 a. The request is therebydelegated to the external handler 108 a, which sends an HTTP request tothe information source, in this example the web server 76, and receivesreturned WML content. The WML content is then returned to the residenthandier 112, which transcodes the WML content into mobiledevice-compatible WMLC content using a WML->WMLC transcoder 74. Thistranscoding could instead involve chained transcoders and/or externaltranscoders as described above. The resultant WMLC content is thenreturned to the mobile device 12 via the dispatcher 22.

In FIG. 12, extension of accepted content types and content transcodingis managed within the IP Proxy system 106 a. FIG. 13 is a signal flowdiagram showing a variation of the request delegation of FIG. 12. InFIG. 13, a request from the mobile device 12 is forwarded to theresident handler 112 by the dispatcher 22. The resident handler 112 thenforwards the request to the connection handler system 108, which startsthe HTTP handler 108 a. The HTTP handler 108 a consults theconfiguration file 102 or lookup table to determine which if anytranscoders may be available to transcode other content types into therequested type, WMLC, and then modifies the request to include theseother content types, WML and HTML in this example. The modified requestis sent to the web server 76, which returns WML content. The returnedWML content is then sent to an appropriate WML->WMLC transcoder 104 a ina transcoder system 86, and the transcoded content is returned to theHTTP handler 108 a and then to the resident handler 112 in the IP Proxysystem 106 a. A response including the WMLC content is sent to themobile device from the handler 112 through the dispatcher to completethe operation.

FIG. 14 is a signal flow diagram showing hand-off of a request to anexternal connection handler. In a hand-off scheme, the IP Proxy system106 c forwards the request via its resident handler 112 to the externalhandler system 108. The connection handler system 108 and theappropriate handler, HTTP handler 108 b in this example, then manage theremainder of the information request/response operation. Once therequest is handed off to an external connection handler system, the IPProxy system 106 c preferably has no further involvement in theoperation.

Referring now in detail to FIG. 14, a request from the mobile device 12is sent to the connection handler system 108. The connection handlersystem 108 invokes the appropriate handler illustratively HTTP handler108 a, which may modify the request to include further content types andsends the request to the information source (web server 76), receivescontent from the information source, and invokes any requiredtranscoding operations in the external transcoding system 86,substantially as described above in conjunction with FIG. 13. Instead ofreturning the transcoded WMLC content to the IP Proxy system 106 chowever, the external connection handler system preferably includes amobile device protocol handler 108 c, which sends a response to themobile device 12.

When a mobile device protocol is different than the request protocolsuch that different handlers are invoked for communication with aninformation source and the mobile device as shown in FIG. 14, the HTTPhandler 108 b and the mobile device protocol handler 108 c areeffectively chained, similar to transcoder chaining described above.Although shown as part of the same connection handler system 108, theHTTP handler 108 b and mobile device protocol handler 108 c may insteadbe associated with different connection handler systems. The connectionhandler system 108 may, for example, download the mobile device protocolhandler 108 c from another connection handler system or invoke themobile device protocol handler at the remote system. It will be apparentfrom the foregoing description that the mobile device protocol handler108 c in FIG. 14 is functionally similar to the dispatcher 22 in that ittranslates between connection handler and mobile device communicationprotocols when necessary.

Connection handlers in the same or different connection handler systemsmay also be chained in order to process an information request frommobile device 12, for example to request the information from aninformation source or to manage transcoding of returned content. Anyconnection handler chaining operations may involve delegation orhand-off, and may preferably be controlled by either a connectionhandler system or an IP Proxy system at which a request was originallyreceived.

It is also contemplated that more than one connection handler system maybe available to any IP Proxy system. As described above for externaltranscoder systems, external connection handler systems may beregistered in one or more registries that may be consulted by an IPProxy system to find available connection handlers. Where connectionhandler chaining is required, connection handler systems may also accessthe registry to locate a particular type of connection handler inanother connection handler system. A registry scheme would also simplifydynamic connection handler management by facilitating discoveryfunctionality to allow IP Proxy systems and connection handler systemsto discover new connection handlers and systems as they becomeavailable. In systems with multiple external connection handler systems,an IP Proxy system may effectively become a load balancing module thatmay distribute incoming mobile device requests among differentconnection handlers.

Connection handlers have been described above primarily in the contextof communication or connection protocols. However, it also contemplatedthat handlers may be implemented for other functions or services,including for example encryption, compression, user authentication, andstate management. Such “service handlers” may possibly be embedded withconnection handlers, but would preferably be distinct modules that maybe chained with connection handlers as needed. A chaining mechanismprovides for more flexibility in connection management and requestprocessing in that a basic connection handler may be chained with asmany service handlers as desired to customize a connection orrequest/response operation. A connection handler system may includeservice handlers, and may also or instead accomplish connection handlerand service handler chaining through downloading or remote execution ofservice handlers in one or more further service handler systems.

EXAMPLE IMPLEMENTATION

An example implementation of an IP Proxy system will now be described.FIG. 15 is a block diagram showing an IP Proxy system implemented in asecure network.

The system 120 in FIG. 15 includes a mobile device 12 that operateswithin a wireless network 14. Through a gateway 15, the mobile devicecan receive and preferably also send data over a WAN 16 such as theInternet. These elements of the system 120 are substantially the same assimilarly labelled elements in FIG. 1. In the system 120 however, the IPProxy system 124 is configured within a private network such as acorporate network 130, behind a security firewall 127, and communicateswith the gateway 15 through a network server computer 122. In aparticular example embodiment, the network server 122 is associated withan email system 128. Two information sources, an internal source 126 andan external source 132, are also shown in FIG. 15.

The network server 122 preferably enables secure communication to themobile device 12, as indicated by the encryption and decryption blocks122 a and 122 b. The network server 122 encrypts any communicationsdirected to a mobile device 12. The intended recipient mobile device 12,using a secret key stored therein, can decrypt encrypted communicationsfrom the network server 122. A mobile device 12 similarly encrypts anyinformation sent to the network server 122, which can be decrypted bythe decryption module 122 b. Those skilled in the art of cryptographywill appreciate that the keys and encryption algorithms used at thenetwork server 122 and mobile device 12 are preferably chosen so that itwould be computationally infeasible to decrypt encrypted informationwithout the required secret key. One preferred encryption scheme istriple-DES (Data Encryption Standard).

Key distribution between a network server 122 and a mobile device 12 maybe accomplished via a secure connection such as a secure physicalconnection between the mobile device 12 and the network server 122, orbetween the mobile device 12 and another computer within the corporatenetwork. Known public key cryptography techniques may instead be usedfor key distribution. In a public key scheme, a public key is used toencrypt information in such a way that the encrypted information may bedecrypted using a corresponding private key. The public key is storedby, and may be retrieved from, a publicly accessible key repositorycommonly referred to as a certificate authority or CA, whereas theprivate key is stored only at a mobile device or system with which thepublic key is associated. Thus, a network server 122 or any other senderthat wishes to send encrypted information to a mobile device 12 mayretrieve the mobile device's public key from a CA and use the public keyto encrypt information destined for the mobile device 12. A mobiledevice 12 may similarly obtain a network server's public key from a CAand use the public key to encrypt communication signals to be sent tothe server.

Regardless of the particular key distribution scheme and encryptiontechniques used, encrypted communications between a mobile device 12 andnetwork server 122 may be used, for example, where corporate or otherprivate information is to be accessed using a mobile device. Considerthe example of the internal information source 126 within the securityfirewall 127, described below with reference to FIG. 16, which is asignal flow diagram illustrating a corporate data access operation. Inkeeping with the above illustrative example operations, FIG. 16 shows anHTTP-based data access operation.

In FIG. 16, an HTTP request is encrypted at the mobile device 12,preferably using a strong encryption routine such as triple-DES (3DES),before it is sent to the network server 122 through the wireless network14 of FIG. 15 and possibly other intermediate networks or components,such as the gateway 15 and WAN 16 shown in FIG. 15. The encryptedrequest is then received by the network server 122 and decrypted in thedecryption module 122 b. The decrypted request is forwarded to the IPProxy system 124, which may proceed to process the request substantiallyas described above. The active handler, the HTTP handler 26 in thisexample, may consult the configuration file 72 or transcoder lookuptable and expand the accepted content types to include content typesthat can be transcoded into the format(s) that can be accepted by themobile device 12. A request, possibly including further content types,is then sent by the HTTP handler 26 to the information source 126, whichthen returns requested information, in WML format in this example. Anappropriate transcoder 74 is loaded and invoked by the HTTP handler 26if necessary and the requested content, preferably in a format requestedby the mobile device 12, is returned to the network server 122 throughthe dispatcher 22. The network server 122 then encrypts the contentreceived from the IP Proxy system 124 in its encryption module 122 a andsends the encrypted content in a response to the mobile device 12. Insome implementations, the protocol conversion or translation operationsassociated with the dispatcher may instead be performed by the networkserver 122.

The information source 126 may be a computer system or data storepreferably configured for operation on the private network 130, such asa file server or other data store accessible through the network 130. Inthe example of a corporate network, the information source 126 mayinclude confidential or otherwise sensitive information that an owner ofthe network 130 strives to keep private. The security firewall 127 isintended to prevent unauthorized access to private network componentsincluding the information source 126. In some situations, the veryexistence of information stored at the information source must remainconfidential. The encryption of the request from the mobile device asshown in FIG. 16 prevents an unauthorized party from determining thecontents of the request without breaking the encryption, which asdescribed above is not computationally feasible for strong encryptionschemes such as 3DES. The request remains encrypted until received bythe network server 122 and decrypted, behind the security firewall 127,as indicated at 134 in FIG. 16. The request is therefore virtually assecure as a request sent from a computer system on the network 130.

Once decrypted, the request is processed by the IP Proxy 124 andinformation source 126 as described above. However, encryption of therequested content by the encryption module 122 a in the network server122 before it is sent to the mobile device 12 similarly ensures that thecontent can only be viewed by the mobile device 12. Confidentialcorporate information therefore remains encrypted and thus secure untilreceived and decrypted at the mobile device 12, thereby effectivelyextending the security firewall 127 to the mobile device 12. Both therequest and the information returned to the mobile device in responsethereto are secure.

In known remote data access schemes such as WAP, gateway systems whichprovide for data access using mobile devices are normally locatedoutside corporate or private premises, at the location of a serviceprovider for example. Any confidential or sensitive informationencrypted at the private premises is decrypted at the gateway system,outside the corporate firewall, and then re-encrypted before being sentto the destination mobile device or devices. The information istherefore in the clear at the gateway system and thus accessible by anowner or operator of the gateway system. Furthermore, the owner oroperator of a private network from which the information was senttypically has no control over security arrangements at the gatewaysystem, such that the information is vulnerable to attacks on thegateway system.

The arrangement shown in FIGS. 15 and 16 wherefore provides secureremote access to private, confidential or otherwise sensitiveinformation. Information is encrypted from end-to-end between thenetwork server 122 and any mobile device 12. Any level of security maybe implemented at the security firewall 127 to protect confidentialinformation stored at an information source such as 126, and whenencrypted by the network server 122, information is not decrypted at anyintermediate point before being received at a mobile device 12. Theinformation is in the clear only “inside” the point 134, behind thesecurity firewall 127, and on the mobile device 12. Securityarrangements such as password or passphrase control are also preferablyimplemented at the mobile device 12 to prevent an unauthorized user fromusing the mobile device or decrypting received encrypted information.For example, computer workstations may be protected bypassword-deactivated system locking and access to a corporate network130 is normally protected by login passwords. Similarly, a password maybe required to use a mobile device 12, while a different passphrase maybe necessary to decrypt any encrypted information stored on the mobiledevice 12. A mobile device 12 and information stored thereon is therebyjust as secure as a network workstation and information stored on anetwork. Such techniques as limited password or passphrase entryretries, mobile device 12 or mobile device memory reset after apredetermined number of failed password/passphrase entries, dynamic andpossibly random password/passphrase updates and the like may be used tofurther improve mobile device security.

For an external information source 132 (FIG. 15), a data accessoperation is substantially the same as shown in FIG. 16, except that theinformation source is outside the firewall 127. The request and responseexchange between the mobile device 12 and the network server 122 may beencrypted, but information exchanged with the information source 132 maybe unsecure. If the information provided by the information source 132is not private or confidential, then unsecure exchange between the IPProxy system 124 and the source 132 will be sufficient for mostpurposes.

One possible measure to improve the security of information beingrequested from an external source 132 is to secure the communicationsbetween the IP Proxy system 124 and the source 132. For example, the IPProxy system 124 may be adapted to support Secure HTTP (HTTPS), SecureSockets Layer (SSL) or other secure communication schemes in order tosecurely access information at the information source 132. Informationfrom the source 132 may thereby be securely transferred to the IP Proxysystem 124 and is then protected by the security firewall 127. Encryptedinformation may be decrypted by the IP Proxy system 124, by the activeconnection handler for example, and transferred to the network server122, which then encrypts the information for transmission to the mobiledevice 12. As above, information is only in the clear behind thefirewall 127. Alternatively, a secure communication session may beestablished between the mobile device 12 and source 132 through the IPProxy 124. In the system of FIG. 15, communications between the mobiledevice 12 and network server 122 would then be double-encrypted.

As shown in FIG. 15, the network server 122 is also associated with theemail system 128. In one embodiment, the network server 122 provides forsending data items from the email system 128 to mobile device 12. Onesuch system is described in detail in U.S. Pat. No. 6,219,694, entitled“System And Method For Pushing Information From A Host System To AMobile Data Communication Device Having A Shared Electronic Address”,and issued to the assignee of the present application on Apr. 17, 2001.The complete disclosure of this patent is hereby incorporated into thisapplication by reference.

Since the network server 122 is also associated with the IP Proxy system124, integrated functionality between the email system 128 and the IPProxy system 124 may be possible. For example, the IP Proxy system 124may use encryption functionality of the network server 122 as well as atransport mechanism via which the network server 122 communicates withthe mobile device 12. Other functions of the network server 122, such asdata compression, for example, may similarly be exploited by an IP Proxysystem 124 to improve the efficiency of use of wireless communicationresources. As described briefly above, content destined for a mobiledevice 12 may be addressed to the mobile device using an email addressin the email system 128 associated with the mobile device user. In thisexample, content forwarded to the mobile device by the IP Proxy system124 may also be stored in the user's mailbox on email system 128 by thenetwork server 122, as indicated in FIG. 15, to thereby provide both arecord of IP Proxy operations and a stored copy of any forwardedcontent. Other integrated functions may include but are in no waylimited to email-based content requests from mobile devices andaddressing of mobile device-destined information by the IP Proxy system124 using an email address on the email system 128. Still furtherintegrated functions may be enabled where a network server 122 or the IPProxy system 124 is associated with any other services.

It will be appreciated that the above description relates to preferredembodiments by way of example only. Many variations on the inventionwill be appreciated by those knowledgeable in the field, and suchvariations are within the scope of the invention as described, whetheror not expressly described. For example, embodiments of the inventionhave been described primarily in the context of an IP-based system.Similar proxy systems for other types of communication systems are alsocontemplated within the scope of the invention. Other types ofconnections, connection handlers and transcoders than those describedabove will also be apparent to those skilled in the art.

Depending upon the particular implementation of a remote data accesssystem and the features to be supported, not all of the elements shownin FIG. 2 are required. Where push services are not supported forexample, the proxy system will not include push services 30.

The invention is also in no way limited to content type indication usingMIME types. MIME types are useful in conjunction with the instantinvention, but are not required to practice the invention. Other contenttype indicators may be substituted for MIME type to indicate the type orformat of requested or received content.

Although the transcoders described above convert between well-knowninformation types or formats, custom transcoders could be developed andimplemented for virtually any information format, including for exampleapplication program file types and proprietary formats. As describedabove, a proxy system in accordance with the Instant invention ispreferably configurable and new content transcoders may be added.

It is also possible that information content from an information sourcemay include multiple different content types, not just a single contenttype as described above. For such multiple-type content, transcoders maybe selected, for example, to transcode the content into a single contenttype, or into multiple content types accepted at a mobile device.Selection of transcoders may be controlled according to any of thetranscoder selection schemes described above. In the case of transcoderselection by a mobile device or information source, a list oftranscoders for any or each part of multiple-type information typecontent may be specified in a connection request, a response to arequest, or a push request. A respective transcoder may be selected andused for each part of the information content having a particularcontent type.

When any part of multiple-type information content cannot be transcodedas desired or required, where a suitable transcoder is not available forexample, only other parts of the information content might be transcodedand sent to a mobile device. Alternatively, a default transcodingoperation as described above may be used to transcode parts ofmultiple-type content. Non-transcoded parts of multiple-type content, orpossibly all of the multiple-type content, could instead be replacedwith a link or other information that may be used to subsequently accessthe information content or parts thereof, and sent to a mobile device.Information indicating the multiple content types and/or required orrecommended transcoders could also be sent to the mobile device. Theinformation content or parts thereof may then be retrieved by the mobiledevice by submitting a connection request or possibly furthertranscoding instructions or an alternate transcoder selection to an IPProxy system.

Furthermore, a proxy system may be implemented in any network, not onlyIn a corporate network as shown in FIG. 15. Installation of a proxysystem in an ISP, ASP, or Virtual Network Operator (VNO) system wouldprovide for secure remote access to network information and securetransfer of information between any network users, including transfersbetween mobile devices of ISP, ASP or VNO users.

Although the invention has been described in detail with reference tocertain illustrative embodiments, variations and modifications existwithin the scope and spirit of the invention as described and defined inthe following claims.

1. A system for providing information content received from aninformation source over a network via a gateway to a wireless mobiledevice, comprising: an IP proxy system configured within a privatenetwork and behind a security firewall for communicating with a wirelessmobile device that is outside of the private network, the IP proxysystem communicating with the wireless mobile device via a gateway andthrough a network server that is also configured within the privatenetwork and behind the security firewall, the network server enablingsecure communication to the wireless mobile device by encryptingcommunications directed to the wireless mobile device and decryptingcommunications from the wireless mobile device, the IP proxy systemcomprising: a transcoding system having a plurality of transcoders, eachtranscoder operable to transcode information content from a respectiveinput content type into a respective output content type; and aconnection handler system external to the transcoding system and havinga plurality of connection handlers, the connection handler system beingoperable to receive a connection request from the wireless mobile devicefor a connection between the information source and the wireless mobiledevice and to select a corresponding connection handler based on theconnection request from the wireless mobile device, the selectedconnection handler being operable to request information content fromthe information source, to transmit information content received fromthe information source to the transcoding system and operable to specifyto the transcoding system one or more transcoders from the plurality oftranscoders to use to transcode the information content, the connectionhandler system further being operable to receive transcoded informationcontent from the transcoding system and to send the transcodedinformation content to the network server for encryption andtransmission to the wireless mobile device.
 2. The system of claim 1,wherein the connection handler system comprises a connection handlerdirectory, the connection handler directory storing connection handlerdata.
 3. The system of claim 2, wherein the connection handler datacomprises connection handler data associated with at least oneconnection handler.
 4. The system of claim 2, wherein the connectionhandler data comprises a network address specifying the location of aconnection handler.
 5. The system of claim 4, wherein the connectionhandler system is operable to access the location specified by thenetwork address, retrieve the connection handler, and store connectionhandler data associated with the connection handler in the connectionhandler directory.
 6. The system of claim 1, wherein the IP proxy systemis operable to receive connection data from the wireless mobile deviceand the connection data includes accept data indicating an acceptablecontent type that the wireless mobile device is operable to receive. 7.The system of claim 6, wherein the connection handler is operable todetermine a received content type of the information content receivedfrom the information source and determine whether the received contenttype matches the acceptable content type.
 8. The system of claim 7wherein the connection handler is further operable to select one or moretranscoders to transcode the information content where the receivedcontent type does not match the acceptable content type.
 9. The systemof claim 7, wherein the connection handler is further operable to sendan error message to the wireless mobile device if the informationcontent cannot be transcoded into the acceptable content type.
 10. Thesystem of claim 1, wherein the transcoding system is operable togenerate and store mapping data comprising transcoding chains, eachtranscoding chain selecting one or more transcoders to transcode theinformation content from an input content type into an output contenttype.
 11. The system of claim 10, wherein the mapping data is updatedupon the addition or deletion of transcoding data.
 12. The system ofclaim 1, wherein the connection handler is operable to specify a list ofcontent types in order of preference and to provide the list of contenttypes to the information source.
 13. The system of claim 12, wherein:the information content includes multiple different content types; andthe connection handler is operable to specify a respective transcoder totranscode the information content of each of the multiple differentcontent types.
 14. The system of claim 1, wherein the information sourceis configured for operation on the private network.
 15. The system ofclaim 1, wherein the information source is configured for operationoutside of the private network.
 16. The system of claim 15, wherein theIP proxy system is adapted to support a secure communication scheme toallow secure access of information at the information source.
 17. Thesystem of claim 16, wherein the secure communication scheme comprisessecure HTTP (HTTPS).
 18. The system of claim 16, wherein the securecommunication scheme comprises Secure Sockets Layer (SSL).
 19. Thesystem of claim 1, wherein the system is operable to store on an emailsystem by the network server information content forwarded to thewireless mobile device by the IP proxy system via the network server.20. A method for providing information content received from aninformation source over a network via a gateway to a wireless mobiledevice, comprising the steps of: providing a transcoding system having aplurality of transcoders, each transcoder configured to transcodeinformation content from a respective input content type into arespective output content type; providing a connection handler systemthat is external to the transcoding system having a plurality ofconnection handlers for different communication protocols forcommunicating with an information source; receiving by the connectionhandler system in a private network behind a security firewall aconnection request from a wireless mobile device, wherein the connectionrequest is decrypted by a network server in the private network behindthe security firewall; selecting a connection handler and establishing aconnection using the selected connection handler; requesting informationcontent from the information source using the selected connectionhandler; receiving information content from the information source bythe selected connection handler; sending the information contentreceived by the selected connection handler to the transcoding system;selecting via the connection handler system a particular transcoder fromthe plurality of transcoders and transcoding the received informationcontent using the selected transcoder to generate transcoded informationcontent; sending the transcoded information content from the transcodingsystem to the connection handler system; and sending via the connectionhandler system the transcoded information content received from thetranscoder system to the network server for encrypting and forwarding tothe wireless mobile device via the gateway.
 21. The method of claim 20,wherein the connection request identifies the information source. 22.The method of claim 21, wherein the step of establishing a connectionwith an information source responsive to the connection requestcomprises the step of sending an information request to the informationsource.
 23. The method of claim 22, wherein: the connection requestconforms to a first communication protocol; and the information requestconforms to a second communication protocol.
 24. The method of claim 23,wherein the second communication protocol is Hypertext Transfer Protocol(HTTP).
 25. The method of claim 22, wherein the connection requestidentifies one or more accepted content types the method furthercomprising the steps of: determining whether any of the plurality oftranscoders are configured to transcode any further content types intoany of the one or more accepted content types; and including the one ormore accepted content types and the further content types in theinformation request.
 26. The method of claim 20, wherein: the connectionrequest identifies one or more accepted content types; and the step ofspecifying to the transcoding system one or more transcoders to usecomprises the step of determining if a received content type of theinformation content may be transcoded into one or more accepted contenttypes.
 27. The method of claim 26, wherein the step of determining if areceived content type of the information content may be transcoded intoone or more accepted content types comprises the steps of: determiningwhether any of the plurality of transcoders are configured to transcodethe received content type into the one or more of the accepted contenttypes; and selecting a transcoder for transcoding the informationcontent into one of the accepted content types where any of theplurality of transcoders are configured to transcode the receivedcontent type into the one or more of the accepted content types.
 28. Themethod of claim 27, further comprising the step of discarding theinformation content where none of the plurality of transcoders areconfigured to transcode the received content type into the one or moreof the accepted content types.
 29. The method of claim 27, furthercomprising the step of passing the information content where none of theplurality of transcoders are configured to transcode the receivedcontent type into the one or more of the accepted content types.
 30. Themethod of claim 26, wherein: the information content comprises multiplecontent types; and the step of determining if a received content type ofthe information content may be transcoded into one or more of theaccepted content types comprises the step of: determining whether any ofthe transcoders are configured to transcode any of the multiple contenttypes into the one or more of the accepted content types; and selectinga respective transcoder for transcoding the information content of eachof the multiple content types into one of the accepted content typeswhere a plurality of the transcoders are configured to transcode aplurality of the multiple content types into the one or more of theaccepted content types.
 31. The method of claim 20, wherein theconnection request identifies one or more accepted content types, andwherein the step of establishing a connection comprises the steps of:searching a configuration file for a set of transcoders configured totranscode information content into the one or more accepted contenttypes; generating a list of respective input content types correspondingto the set of transcoders; and sending the list of respective inputcontent types and the one or more accepted content types to theinformation source.
 32. The method of claim 20, wherein the networkserver in response to the step of sending the transcoded informationcontent to the network server compresses the transcoded content.
 33. Themethod of claim 20, wherein the information source is configured tooperate within the private computer network behind the securityfirewall.
 34. The method of claim 20, further comprising the steps of:generating a list of transcoders according to an order of preference;and selecting one of the transcoders in the list of transcoders based onthe order of preference.
 35. The method of claim 20, wherein the inputcontent types and output content types include content types selectedfrom the group consisting of Wireless Markup Language (WML), HypertextMarkup Language (HTML), compiled WML (WMLC) and Extensible MarkupLanguage (XML).
 36. The method of claim 20, wherein the informationsource is configured for operation outside of the private network. 37.The method of claim 36, wherein the step of establishing a connectionusing the selected connection handler comprises establishing aconnection using a secure connection scheme to allow secure access toinformation at the information source.
 38. The method of claim 37,wherein the secure communication scheme comprises secure HTTP (HTTPS).39. The method of claim 37, wherein the secure communication schemecomprises Secure Sockets Layer (SSL).
 40. The system of claim 10,wherein the connection handler is operable to determine a receivedcontent type of the information content received from the informationsource, to determine an acceptable content type that the wireless mobiledevice is operable to receive, and to specify one of the transcodingchains to transcode the information content from the received contenttype into the acceptable content type.
 41. The system of claim 12,wherein the connection handler is operable to determine a receivedcontent type of the information content received from the informationsource, to determine an acceptable content type that the wireless mobiledevice is operable to receive, and to specify the one or moretranscoders to transcode the information content from the receivedcontent type into the acceptable content type.
 42. The system of claim 1wherein the transcoder system is situated at a location remote from thelocation of the connection handler system.
 43. The method of claim 20wherein the transcoder system is situated at a location remote from thelocation of the connection handler system.